Overview

  • pada kenyataannya beban terhadap aplikasi selalu berubah
  • Dengan menggunakan cloud, perubahan beban tersebut dapat diantisipasi dengan menaik dan menurunkan jumlah EC2 instance
  • tujuan dari ASG adalah
    • melakukan scale out (menambah EC2 instance) untuk mengantisipasi kenaikan beban
    • Melakukan scale in (menghapus EC2 instance) untuk menyesuaikan jika terjadi penurunan beban
    • jumlah minimum dan maksimum instance dapat disesuaikan berdasarkan kebutuhan
    • ASG secara otomatis akan mendaftarkan instance baru ke load balancer
    • EC2 instance akan di-create ulang oleh ASG jika instance sebelumnya diterminated (misalnya karena unhealthy)
  • ASG free
    • yang ditagihkan ke user hanya EC2 instance running di dalam ASG
  • minimum capacity
    • parameter ASG berapa jumlah EC2 instance minimal yang diinginkan pada ASG (batas scale-in)
  • desired capacity
    • berapa jumlah instance yang diinginkan pada ASG
    • minimum capacity + jumlah instance yang bisa ditambahkan
  • Maximum capacity
    • jumlah maksimum instance
    • Desired capacity + jumlah scale out

ASG x ELB

070202-asg.drawio.png

  • ASG dapat diintegrasikan dengan ALB
    1. Jika di dalam ASG terdapat 4 instance yang tergistrasi pada ASG
    2. ELB akan mendistribusikan traffic ke semua instance yang terdaftar
    3. ELB juga memiliki kemampuan memeriksa health dari EC2 instance
    4. healthcheck tersebut akan diteruskan ke ASG. Sehingga ASG dapat melakukan terminate pada instance yang ditandai unhealthy oleh ELB
    5. Ketika scale out, ELB akan mendistribusikan traffic ke EC2 instance yang ditambah tersebut

ASG Attribute

  • Untuk membuat sebuah ASG, attribute berikut diperlukan
    • Launch Template, terdiri dari
      • AMI+Instance type
      • EC2 user data
      • EBS volume
      • Security Groups
      • SSH Key Pair
      • IAM Roles dari EC2 instances
      • Network + subnet info
      • Load Balancer Info
    • Min Size, Max Size, Initial Capacity
    • Scaling Policy

CloudWatch Alarm x Scaling

  • User dapat melakukan scaling pada ASG dengan menggunakan CloudWatch Alarm
  • trigger dari CloudWatch Alarm dapat menjadi landasan untuk melakukan scaling out
  • CloudWatch Alarm akan memonitor metrik
    • Average CPU
    • dan metrik yang lain
    • Example :
      • jika average CPU pada keseluruhan EC2 instance pada ASG terlalu tinggi bebannya maka alarm akan dirilis sebagai trigger ASG

Scaling Policies

  • terdapat beberapa scaling policies untuk autoscaling group

Dynamic Scaling

  • Target Tracking Scaling
    • paling sederhana untuk dibuat
    • Konsepnya user menentukan metric untuk ASG, misal CPU utilization
      • i want the average ASG CPU berada di kisaran 40%
  • SImple / Step Scaling
    • define CloudWatch Alarms yang akan ditrigger pada kondisi tertentu, dengan action penambahan/pengurangan instance
    • Contoh :
      • ketika CloudWatch Alarm melakukan trigger (kondisi CPU >70%), maka tambahkan 2 instance
      • ketika CloudWatch Alarm melakukan trigger (kondisi CPU <30%), maka hapus 1 instance

Scheduled Scaling

  • scaling yang digunakan untuk mengantisipasi kenaikan/penurunan beban berdasarkan pattern yang sudah diketahui
  • Misal, naikkan kapasitas ke 10 pada jam 5 hari jumat

Predictive Scaling

  • aws secara otomatis memprediksi beban dan melakukan penjadwalans scaling berdasarkan pattern yang dipelajari
  • menggunakan ML

Metrik apa yang digunakan sebagai landasan Scaling

  • CPUUtilization : Rata - rata penggunaan CPU lintas EC2 instance
  • RequestCountPerTarget: untuk memastikan jumlah request di tiap EC2 instance stabil
  • Average Network In/Out : jika aplikasi memiliki kebutuhan yang tinggi terhadap network
  • Custom Metrik yang lain : yang dipush menggunakan CloudWatch

Scaling Cooldowns

  • setelah aktivitas scaling dilakukan. Terdapat periode cooldown (default : 300 detik)
  • Selama masa cooldown, ASG tidak akan melakukan aksi scaling apapun (launch/terminate instance).
    • Untuk memberikan kesempatan sistem sampai pada kondisi stabil
  • Direkomendasikan untuk menggunakan AMI yang sudah siap pakai, untuk mengurangi waktu konfigurasi sehingga instance lebih cepat untuk siap melayani request. Sehingga waktu cooldown yang dibutuhkan tidak terlalu lama